home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000049_owner-urn-ietf _Fri Jan 31 12:59:42 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA04057 for urn-ietf-out; Fri, 31 Jan 1997 12:59:42 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA04051 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 12:59:40 -0500
  3. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA26659  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:59:37 -0500
  5. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id LAA16540; Fri, 31 Jan 1997 11:59:19 -0600 (CST)
  6. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  7. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id LAA04496; Fri, 31 Jan 1997 11:59:36 -0600 (CST)
  8. Date: Fri, 31 Jan 1997 11:59:36 -0600 (CST)
  9. Message-Id: <199701311759.LAA04496@void.ncsa.uiuc.edu>
  10. To: "Ron Daniel Jr." <rdaniel@lanl.gov>
  11. Cc: Daniel LaLiberte <liberte@ncsa.uiuc.edu>,
  12.         "URL mailing list" <ietf-url@imc.org>, <urn-ietf@bunyip.com>
  13. Subject: Re: [URN] Re: Relative URLs and URNs
  14. In-Reply-To: <3.0.32.19970131103134.00914c00@acl.lanl.gov>
  15. References: <3.0.32.19970131103134.00914c00@acl.lanl.gov>
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. Ron Daniel, Jr. writes:
  22.  > The point I was trying to make is that the presence of the relative
  23.  > URLs is not helping us as we make the transition to URNs.
  24.  
  25. Relative URLs (which are relative URIs intended to be interpreted
  26. relative to an absolute URL) would not interfere with a transition
  27. to URNs if you keep the same absolute URL base.  But if you want
  28. each and every one of your documents to have a URN, and you can't use
  29. relative URNs then you have to use absolute URNs.  That much is clear.
  30.  
  31.  > The URNs
  32.  > we are assigning are very different from the URLs we currently use.
  33.  > For example, the document at
  34.  >   http://www.acl.lanl.gov/URN/index.html
  35.  > might get a FPI of
  36.  >   -//LANL ACL//199703014039//EN
  37.  > which results in the URN
  38.  >   urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN
  39.  
  40. Is it true that the fpi URNs are non-hierarchical, or if they have
  41. hierarchical structure, you don't want to expose it?  (I'd recommend
  42. that the syntax of fpi URNs expose the structure and avoid reserved
  43. chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN)
  44.  
  45.  > Relative URNs only save you work if the next
  46.  > namespace you use is very similar to the one you currently use.
  47.  > If they are not similar, then you have to edit the documents, just
  48.  > as you would have to do if you had used absolute identifiers.
  49.  
  50. Or, another way of looking at it is that (absolute) URNs only save you
  51. work if the structure of the name space is similar to the one you
  52. currently use.  If a relative URI can be used with either an http URL
  53. base or a path URN base, you don't have to change anything but the base.
  54.  
  55.  > This is not a damning indictment of relative URNs, it just points out
  56.  > that they are unlikely to save one a significant amount of work.
  57.  
  58. Relative URNs *are* likely to save one a significant amount of work *if*
  59. you use a name space that is hierarchical and that supports relative
  60. URNs.
  61.  
  62. dan